2.8. General Comments

It’s not clear if the questions are for reading or for writing Vendor’s product really doesn’t implement an iCalendar protocol.

Vendor licenses its operating system as a platform for handset manufacturers to build their products with. The answers to the questionnaire describe what conformance is enabled by the PIM data stores provided in a particular version of the vendor’s operating system Other versions do not provide iCalendar parsing/generation or RFC 2446 implementation — this functionality will be provided by handset manufacturers.

Vendor has created a toolkit, which at its lowest level is built on an RFC 2425 encoder/decoder, so it’s possible to encode ANYTHING. An app built on this toolkit may encode according to the MUST rules, or may not, so many of the questions don’t really apply. You can do it right, or you can do it wrong, and on decoding, vendor tries and be liberal in what is accepted. So, most of answers are either OTHER or NO. Despite this, vendor feels compliance is pretty good (in the things implemented), it’s just that it’s very hard to write a flexible toolkit that makes it impossible to generate calendars that break the rules.

Lots of stuff vendor hasn’t done are easy, just haven’t had the time or need for them yet.

In general, vendor does not always return errors for incorrect data input. However, they consume correct data properly, and produce right data in most of the above cases.

Vendor has always considered it unusual that monthly recurrence rules that might fall outside the range of shorter months result in the instance being skipped. Vendor actually forbids such a meeting, but if iCalendar is to allow such a recurrence rule, it should follow the lead of many other applications and pull the instance back to the last day of the month. Currently, it’s just a little silly. If a company’s employees get paid on the 15th and 30th of every month, shouldn’t my iCalendar-compliant accounting application be capable of doing “the right thing” in February?

Vendor’s resource scheduler product does not accept iCal documents, only generates them. Currently does not create recurrence data.

Vendor’s library provides applications with support for recurrences mainly in three areas:

• translating RFC2445-style recurrences into an internal structure;

• creating recurrences (and exceptions) with a procedural API;

• iterating over instances.

Everything else is expected to be handled by the application.

More tests are needed. This is a direct consequence of the extreme complexity of the specification and the many corner cases that need to be tested.
(What are the complex areas and what corner cases need to be flushed out?)